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ABSTRACT 

The  application  of  computers  in 
acquisition  and  logistics  support  is  a 
major  requirement  of  future  weapons 
systems  acquisitions.  Although  the 
design  of  the  SEAWOLF  preceded  most 
new  DOD  sponsored  requirements,  the 
program  incorporated  many  initiatives 
that  will  serve  as  prototypes  for 
future"  acquisitions. 

The  SEAWOLF  Program  is  employing 
computer  technology  to  integrate  the 
design,  production  and  logistic 
support  functions  of  the  ship's  life 
cycle.  The  transportability  of 
electronic  data  from  the  design  phase 
to  construction,  and  on  to  logistics 
is  key  to  improving  efficiency  and 
more  closely  linking  designer, 
shipbuilder  and  maintainer. 

SFAWOLF  is  an  important  step  in  the 
overall  effort  to  improve  weapons 
system  acquisition  efficiency. 

Lessons  learned  by  SEAWOLF  will  be 
valuable  in  preparing  other 
acquisition  programs  to  take  advantage 
of  the  integration  of  computer  data 
bases  that  can  bring  greater  success 
in  the  execution  of  design,  production 
and  logistics  support  phases. 

INTRODUCTION 

The  life  cycle  of  a  ship  or  any 
weapons  system  in  general  is  divided 
rnto  many  phases.  These  phases  extend 
from  the  first  drawing  that  defines 
the  ship  at  the  highest  level  during 
conceptual  design  to  the  day  when  the 
last  unit  completes  its  final  mission. 
One  constant  that  has  existed  for 
centuries  is  the  need  to  transfer 
information.  In  early  ship 
construction  a  scale  model  constructed 
in  wood  may  have  been  the  only  vehicle 
necessary  to  transfer  the  designer's 
knowledge  to  the  shipwright.  The  next 
step,  and  the  one  we  are  for  the  most 


part  living  with  today,  is  the 
transfer  of  information  from  designer 
to  constructor  to  operator  and 

logistician  using  paper  as  the  medium. 
Today,  the  information  takes  the  form 
of  drawings,  specifications, 
maintenance  plans  and  standards, 
technical  publications,  piece  part 
support,  allowances  and  a  seemingly 
infinite  number  of  variations.  The 
desire  to  better  control  the  life 
cycle  functions  of  a  ship  has  led  to 
the  proliferation  of  huge  volumes  of 
paper  at  each  point  of  the  process. 

The  wasteful  part  of  this  process  is 
the  fact  that  we  constantly  recreate 
data  that  undoubtedly  a  person 
associated  with  some  previous  part  of 
the  life  cycle  has  had  at  their 
fingertips . 

The  practical  application  of 
managing  the  data  created  during  a 
ship  (or  any  other  weapons  system) 
life  cycle  is  an  immense  task.  Figure 
1  depicts  a  very  high  level  summary  of 
the  major  interfaces.  There  are  many 
points  of  transfer  and  each  one  has 
its  own  specific  requirements  that 
must  be  satisfied.  For  example,  the 
interface  between  design  and 
construction  is  a  particularly 
important  one  in  the  SEAWOLF  Program 
today. 

The  shipbuilder  must  be  provided  an 
array  of  design  products,  the  largest 
volume  of  which  is  drawings  and 
associated  material  information. 
Conventionally,  this  point  of  data 
transfer  has  been  strictly  limited  to 
the  delivery  of  reproducible  paper 
drawings.  However,  the  ability  of  a 
program  to  provide  that  information  in 
a  data  transfer  medium  other  than 
paper  is  in  today' s  increasingly 
computer  oriented  environment  not  only 
an  attractive  option,  but  in  the  near 
future  will  be  a  requirement. 
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FIGURE  1.  LIFE  CYCLE  DATA  INTERFACES 


Today' s  program  manager  must  be 
expected  to  understand  the  methodology 
of  managing  data.  The  program  manager 
will  look  at  the  Department  of  Defense 
specifications,  the  capability  of 
potential  prime  contractors  and 
mandate  contractual  language  to 
implement  design,  construction  and  ILS 
requirements.  There  are  many  key 
decision  points  within  an  acquisition 
program  concerning  the  vehicles  by 
which  data  will  be  created,  stored  and 
exchanged.  The  most  critical 
decisions,  from  the  SEAWOLF 
experience,  are  the  decisions  made 
during  the  preliminary  phases  of 
design  and  implemented  m  the  detail 
design  contract.  The  detail  design 
phase  creates  large  amounts  of  data 
and  a  later  change  of  course  would  in 
all  likelihood  be  expensive  and 
difficult  to  execute.  Therefore,  the 
topic  of  creating  and  utilizing 
electronic  data  bases  in  weapons 
system  acquisition  will  receive 
increasing  visibility  at  high  level 
forums,  such  as  the  ship  production 
symposium. 


EARLY  SEAWOLF  INITIATIVES 

The  SEAWOLF  Program  preceded  most 
DOD  initiatives  to  improve  the  methods 
in  which  life  cycle  information  is 
handled.  Sufficient  technology  was 
available  at  both  submarine  design 
yards,  Newport  News  Shipbuilding  (NNS) 
and  General  Dynamics,  Electric  Boat 
Division  (EB  Div) ,  to  establish  the 
contractual  mandate  that  the  EB 
Div/NNS  design  be  entirely  CAD  based. 
We  believe  that  history  will  support 
that  this  forward  looking  decision  is 
one  of  the  single  most  important 
milestones  in  the  Program's  history. 

To  support  a  competitive  acquisition 
strategy,  the  Program's  plan  to  go 
forward  with  a  digitally  based  design 
had  to  deal  with  the  difficult  problem 
of  developing  the  capability  to 
transfer  design  products  between  the 
two  submarine  design  yards,  and 
eventually  to  a  shipbuilder.  The 
incompatibility  of  the  design  yard  CAD 
systems  left  serious  doubts  as  to 
whether  or  not  the  EB  and  NNS  design 
data  could  be  transferred  cost 
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effectively.  There  were  three  options 
explored  to  solve  this  problem:  1) 
direct  both  design  yards  to  use  the 
same  CAD  system,  2)  Develop  a  direct 
translator  between  the  two  existing 
systems,  or  3)  work  with  a  neutral 
format  translation  process, 
specifically  the  Initial  Graphics 
Exchange  Specification  (IGES) . 

The  first  option  would  have  incurred 
a  very  large  expense.  The  second 
option  was  regarded  as  being  too 
inflexible  since  data  from  a  third 
system  may  not  be  usable  and  future 
upgrades  of  existing  software  at 
either  design  yards  could  necessitate 
revisions  to  the  direct  translator. 

The  third  option  had  the  potential  to 
be  cost  effective  and  flexible, 
however,  it  was  recognized  that  large 
scale  IGES  transfers  in  shipbuilding 
had  not  been  done  before.  The  program 
selected  the  IGES  option  and  accepted 
the  task  to  go  through  the  development 
effort  necessary  and  make  this  medium 
of  transfer  an  effective  vehicle.  In 
addition  to  the  two  and  three 
dimensional  graphics  information  that 
IGES  would  handle  the  need  to  transfer 
processible  or  "field"  type  text  data 
was  necessary.  In  1985  the  SEAWOLF 
Program  organized  data  transfer 
working  groups  to  bring  EB  Div  and  NNS 
people  together  and  provide  the 
framework  for  transferring,  in  most 
cases  in  parallel  with  the  hard  copy 
deliverable,  three  types  of  data: 

o  Drawings  (2D  Graphics) 
o  Product  Model  (3D  Data) 
o  Processible  Data  Elements 

A  working  group  was  assigned  to  each 
of  these  data  types  with  the  goals  of 
specifically  defining  what  contract 
deliverables  would  be  transferred, 
developing  the  written  transfer 
procedures,  and  thoroughly  testing  the 
transfer  process  to  validate  the 
procedures.  The  charter  of  these 
working  groups  was  to  bring  electronic 
data  transfer  from  a  goal  to  a 
reality.  Additionally,  the  procedures 
developed  had  to  be  rigorous  and  clear 
for  the  digital  product  to  be  made  a 
deliverable  in  the  SEAWOLF 
Construction  Contract. 


SEAWOLF  DIGITAL  DATA  TRANSFER  WORKING 
GROUPS 

The  philosophy  behind  the  working 
groups  was  that  knowledgeable 
personnel  from  Electric  Boat  and 
Newport  News,  with  guidance  from 
NAVSEA,  were  capable  of  developing  the 
tools  necessary  to  transfer  SEAWOLF 


data  electronically.  Although  the 
management  at  both  companies  set  the 
course,  the  working  group's  efforts 
for  the  most  part  were  undertaken  by 
Computer  Aided  Design  (CAD)  support 
engineers,  for  the  IGES  type  transfer, 
ana  material  specialists,  in  the 
processible  text  transfer.  The  groups 
met  about  once  a  month  and  devised 
their  own  methods  of  developing  the 
products  required  by  the  detail  design 
contract.  The  statement  of  work  of 
the  contract  required  the  design  yards 
to  develop  and  refine  procedures  for 
the  conversion,  storage,  validation, 
and  exchange  of  design  information 
(processible  text,  drawings  and 
product  model  including  piping  and 
structural  information)  m  digital 
form  .  In  addition,,  as  part  of  the 
Contract  Data  Requirements  List  (CDRL) 
the  delivery  of  procedures  was 
required.  These  procedures  (see 
Figure  2)  would  become  the  basis  of 
data  transfer  and  invoked  in  future 
contracts . 


1.  DIGITAL  DRAWING  EXCHANGE 
2  DATA  ELEMENT  DICTIONARY 

3.  PROCESSIBLE  DATA  EXCHANGE 

4 .  STRUCTURE  EXCHANGE 

5.  PIPING  DATA  EXCHANGE 

6.  NON. PROCESSIBLE  TEXT  EXCHANGE 

7.  DIGITAL  PRODUCT  DATA  CONTROL 

8.  DIGITAL  DATA  TEST  SET 


FIGURE  2  SEAWOLF  DATA  EXCHANGE  PROCEDURES 


Drawing  Transfer 

The  successful  exchange  of  drawings 
within  the  SEAWOLF  Program  from  design 
yard  to  construction  yard  allows  the 
shipbuilder  to  have  a  computer  usable 
(vector  notation)  drawing  available. 
The  utility  of  being  able  to  work  with 
a  drawing  with  the  same  capability  as 
if  it  had  been  created  on  ones  own  CAD 
system  is  significant.  Additionally, 
the  option  to  create  a  SEAWOLF  data 
base  at  another  site,  such  as  a 
planning  yard,  is  achievable. 
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The  transfer  of  drawings  using  IGES 
as  the  vehicle  is  a  complex  process. 

The  complexity  is  the  result  of  the 
methods  in  which  individual  CAD 
vendors  represent  the  many  visual 
devices  that  convey  information. 

Something  as  simple  as  the  width  (or 
font)  of  a  line  can  create  a  thorny 
translation  problem.  Although  IGES 
translators  were  available  from  each 
of  the  CAD  vendors  whose  products  were 
involved  in  SEAWOLF  design,  the 
initial  attempts  to  transfer  data 
resulted  in  drawings  at  the  receiving 
site  that  did  not  resemble  the 
original  drawing.  The  major  reasons 
for  these  drawing  exchange 
difficulties  were  rooted  in  four 
areas : 

o  Translator  Problems 

o  IGES 

o  System  Differences 

o  User  Errors 

Each  problem  was  documented  and 
categorized  by  priority  and  method  of 
solution.  Translator  problems  were 
resolved  by  feeding  back  information 
to  the  CAD  vendor  who  provided  the 
translator.  Both  vendors 
involved  (IBM  and  CV)  were  very 
receptive  to  the  requests  from  the 
SEAWOLF  Data  Transfer  working  groups 
for  improvements  in  the  translator 
software  and  most  problems  have  been 
solved.  Recommendations  to  change 
IGES  were  referred  to  the  IGES 
committee  and  the  National  Bureau  of 
Standards  (now  National  Institute  of 
Standards  and  Technology)  .  This 
process,  although  slower  than  working 
through  the  CAD  vendors,  resulted  in 
useful  changes  that  improved  the 
translation  process.  Working  with  the 
CAD  vendors  and  IGES  had  the  advantage 
of  not  being  a  direct  cost  to  the 
government .  The  feedback  provided  by 
the  SEAWOLF  working  groups  to  the  CAD 
vendors  and  the  IGES  committee 
provided  a  basis  for  a  significant 
product  improvement  to  the  vendors 
translators  and  IGES. 

In  the  event  a  solution  to  a  problem 
was  required  prior  to  being  addressed 
in  the  translator  or  IGES,  an  interim 
solution  to  most  problems  was  resolved 
by  creating  "work  around"  software  at 
the  sending  or  receiving  site.  System 
differences  and  user  errors  were 
corrected  through  the  institution  of 
internal  procedures  within  each 
company  to  provide  uniform  CAD 
products  ana  a  SEAWOLF  drawing 
transfer  procedure  to  govern  exchanges 
of  drawings  between  sites.  In 
addition,  a  standard  set  of  test  cases 
was  developed  to  check  translator 
integrity  when  a  new  revision  of  CAD 
Software  was  introduced  by  either 
design  yard.  The  program  to  improve 


drawing  transfer  has  been  very 
successful.  The  SEAWOLF  effort  has 
achieved  a  consistently  accurate 
transfer  of  information  with  only 
minor  problems  that  are  well 
documented  and  easily  corrected  at  the 
receiving  site,  as  part  of  the  drawing 
validation  process. 

Future  Acquisition  Programs  must 
decide  what  medium  is  required  to 
transfer  drawings.  The  SEAWOLF 
Program  chose  IGES  as  the  medium  to 
provide  computer  usable  drawings  at 
various  sites.  Options  other  than 
iges,  i.e.,  raster  images,  can  provide 
improved  transfer,  storage  and 
retrieval  capability,  but  without  the 
virtue  of  being  cAD  usable.  A  Raster 
image  is  a  series  of  dots  that  can  be 
electronically  stored  to  represent  a 
2D  graphic.  The  advance  of  technology 
in  converting  Raster  to  vector  may 
someday  allow  the  Raster  transfer  to 
become  the  2D  transfer  medium  of 
choice. 


Product  Model  Transfer 

The  transfer  of  product  model  or  3D 
information  is  an  important  function, 
particularly  from  the  standpoint  of 
manufacturing.  The  accurate  3D 
description  of  parts  that  comprise  a 
ship  is  the  entry  point  for  advanced 
manufacturing  systems.  A  hallmark  of 
the  SEAWOLF  Program  is  the  contractual 
requirements  for  both  design  yards  to 
deliver  piping  and  structural  product 
model  information  to  the  shipbuilder. 

Moving  information  through  a 
manufacturing  process  is  a  complex 
procedure.  In  most  cases  the  time  to 
create  the  paper  or  software  products 
that  support  the  fabrication  of  each 
piece  takes  many  times  longer  than  the 
actual  time  to  manufacture.  The  need 
to  reduce  fabrication  costs  has  driven 
most  shipbuilders  to  implement 
producibility  enhancement  programs 
that  reduce  the  time  and  complexity  of 
the  manufacturing  process.  One  method 
revolves  around  cringing  numerical 
control  machinery  onbcard  and 
interfacing,  them  with  computers.  A 
generic  computer  integrate 
manufacturing  system  is  depicted  in 
Figure  3.  To  take  full  advantage  of  a 
systemts  potential,  the  maximum  amount 
of  information  is  transferred 
electronically  from  computer  to 
computer  through  direct  links.  Down 
loading  to  paper  at  any  point  in  the 
process  and  then  recentering  the  data 
into  another  data  base  represents 
failure.  The  front  end  of  the  system 
is  the  CAD  station  work  station  that 
originates  the  designer's  description 
of  the  piece  to  be  fabricated, 
whatever  it  may  be.  In  the  case  of 
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SEAWOLF  that  piece  may  be  designed  at 
either  NNS  or  EB.  In  order  to 
electronically  link  the  design  data 
base  to  the  manufacturing  system  of 
the  shipbuilder,  the  SEAWOLF  program 
developed  and  is  continuing  to  develop 
the  procedures  to  utilize  IGES  based 
transfer  of  product  model  data. 


A  working  group,  similar  to  the 
drawing  transfer  working  group, 
developed  a  procedure  to  guide  the 
process  of  moving  structural  and 
piping  product  model  data  from  design 
yard  to  shipbuilder.  In  addition  to 
the  procedure  development, 
considerable  testing  and  resolution  of 
problems  that  the  testing  brought  out 
took  place.  The  final  step  in  the 
development  phase  has  been  to  transfer 
data  from  designer  to  manufacturer  and 
use  that  data  to  cut  steel  or  bend 
pipe. 

In  a  weapons  system  acquisition,  the 
program  manager  must  determine  if  the 
transfer  of  product  model  type 
information  is  required  to  support  the 
manufacture  of  the  system.  The 
program  should  require  sufficient 
procedure  development  and  testing  to 
insure  that  design  data  will  fully 
support  construction.  An 
understanding  of  the  manufacturing 


capabilities  and  requirements  of 
potential  manufacturers  is  essential 
to  making  the  correct  decisions. 
Although  the  up  front  implementation 
of  a  data  transfer  program  as  part  of 
design  is  an  additional  design 
expense,  in  reality  it  is  a  high 
leveraged  investment  that  will  make 
the  weapons  system  more  affordable 
over  the  life  cycle. 


Processible  Text  Transfer 

The  text  information  transferred 
with  the  drawings  using  the  IGES 
process  is  not  computer  usable.  In 
other  words,  information  such  as  parts 
data  cannot  be  electronically  pulled 
from  the  drawings  to  access  other 
computer  files.  Although  future  data 
exchange  standards  (notably  PDES)  plan 
to  offer  this  capability,  at  present 
intelligent  or  processible  text  data 
must  be  transmitted  separately  in  a 
relational  data  base  that  utilizes  a 
data  element  dictionary  (DED)  .  The 
DED  is  simply  a  definition  of  the  data 
element  necessary  to  transmit 
information.  The  data  element 
definition  is  extensive.  Each  element 
requires  a  field  name,  number  of 
characters,  data  code,  references, 
description,  input  instructions, 
examples,  edit/screening  provisions 
and  data  structure. 
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as  in  drawings  and  product  model 
transfer,  a  working  group  was  formed 
to  develop  the  guidelines  necessary  to 
exchange  processible  text.  This 
effort  included  assembling  the 
elements  of  the  data  element 
dictionary  and  preparing  the  procedure 


to  guide  the  actual  transfer.  The 
most  difficult  activity  was  the  large 
guantity  of  elements  that  had  to  be 
identified  and  then  individually 
defined.  An  example  of  a  data  element 
is  shown  in  Figure  4. 


FIELD  NAME: 

ND  Matrix 

NUMEER  OF  CHARACTERS 

1  each 

DATA  CODE: 

PNC129A, B, C, D,  E,  and  F 
REFERENCES 

(a)  Table  47,  NDT  Codes 
DESCRIPTION: 


Identifies  applicable  non-destructive  test  requirements  (i.e.  VI,  RT,  PI,  01, MI,  and  MN) 
performed  on  the  item  (DAPN) . 

The  Codes  (Y/N)  in  these  fields  relate  to  tests  listed  in  Reference  (a) . 

INPUT  INSTRUCTIONS: 

o  Enter  the  letter  "Y"  if  the  particular  test  applies  to  the  item,  or  enter  "N"  if  not  required. 
"'Blank"  indicates  NDT  consideration  not  made/not  applicable. 

Test  designation  sequence: 

VT  RT  PT  UT  MT  and  MN 

EDIT/SCREENING  PROVISIONS:  (Performed  by-) 

0  Computer-  Reject  Code  other  than  Y,N,or  blank. 

TYPE  V  R  P  U  M  M 

TEST  T  T  T  T  T  N 

Applicable  (Yes/No)  Y  Y  N  N  N  N 

EDIT/SCREENING  PROVISIONS  (Performed  by) 

p  Computer  -  Reject  Code  other  than  Y,N,or  blank. 

DATA  STRUCTURE: 


A(l)  each  (Alphabetic) 


FIGURE  4.  EXAMPLE  OF  SEAWOLF  PROCESSIBLE  TEXT  DATA  ELEMENT 
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The  working  group  further  defined 
the  categories  of  data  to  be 
transferred.  A  list  of  the  more 
common  data  reports  exchanged  is  shown 
in  Figure  5.  As  people  working  in  the 
fields  of  procurement,  manufacturing, 
non-destructive  testing,  weight 
control  and  most  notably  logistics 
support  understand  the  utility  of  the 
computer  in  their  jobs;  the  importance 
of  data  exchange  increases  so  that  the 
re-input  or  re-creation  of  data 
received  from  another  source  is  not 
required. 


SEAWOLF:  A  MAJOR  MILESTONE  IN  DATA 

TRANSFER 

The  effort  of  the  SEAWOLF  working 
groups  have  brought  the  state  of  data 
transfer  to  the  point  where  the 
program  is  contractually  supporting 
the  transfer  of  production  information 
from  design  yard  to  shipbuilder.  The 
culmination  of  this  effort  is  very 
much  like  a  commencement  exercise. 

The  door  has  been  opened  and  the 
desirability  of  expanding  the  scope  of 
the  data  transfer  effort  is  apparent. 
The  working  groups  have  been  tasked  to 
develop  the  procedures  and  conduct  the 
testing  to  facilitate  a  future 
transfer  of  ventilation  and  electrical 
cabling  design  data.  The  working 
groups  will  look  at  transferring  data 
that  is  directly  available  from  the 
data  base  such  as  cable  routing 
information  and  tabular  listing  of 
ventilation  shapes  and  their 
dimensions.  Further,  the  groups  will 
explore  the  transfer  of  the  3D  product 
model  of  ventilation  and  electrical 
system  geometry.  The  end  result  will 
be  similar  to  the  structure  and  piping 
programs,  as  the  ventilation  and 
electrical  construction  drawings  are 
issued,  a  parallel  package  of 
electronic  data  will  be  issued  to 
support  the  manufacturing  and  planning 
operations . 

Beyond  the  present  program  of 
providing  data  which  represents  the 
transfer  of  design  information  is  the 
desire  to  increase  the  scope  of  the 
transfer  to  include  manufacturing  type 
information.  For  example,  the  seawolf 
plate  cutting  facility  takes  the 
transferred  design  or  "neat"  part  and 
adds  information  such  as  the  bevel 
required  for  a  specific  welding 
process  and  any  extra  stock  necessary 
for  final  fit  up.  If  commonality 
between  manufacturing  sites  can  be 
reached  in  the  methodology  of 
preparing  a  design  part  for 
manufacture,  then  the  information 
added  by  the  manufacturing  planner 
will  be  required  only  one  time  during 

the  life  of  that  part. 


DATA  EXCHANGE  DOCUMENT 

1.  ENGINEERING  PARTS  LIST 

2.  LOGISTIC  SUPPORT  ANALYSIS  CONTROL 
NUMBER  MASTER  FILE 

3.  STOWAGE  INFORMATION 

4.  MACHINERY  MATERIAL  HISTORY 

5.  PREFERRED  PARTS  SELECTION  LIST 

6.  SHIP'S  DRAWING  SCHEDULE 

7.  HIGH  IMPACT  SHOCK  QUALITY  DATA 

8.  RADIOGRAPHIC  SHOOTING  SKETCH  DATA 

9.  PROCUREMENT  SUMMARY  INDEX 

10.  WEIGHTS  AND  MOMENTS 

11.  NON-DESTRUCTIVE  TEST  DATA 

FIGURE  5.  SELECTED  PROCESSIBLE  TEXT  REPORTS 
SUPPORTED  BY  THE  SEAWOLF  DATA 
ELEMENT  DICTIONARY 


INTEGRATION  OF  DESIGN  AND  LOGISTICS 
SUPPORT 

The  integration  of  the  SEAWOLF 
design  and  construction  has  been  well 
documented  in  prior  presentations. 

The  creation  of  the  modular  build 
strategy,  formalized  by  planning  and 
sequence  documents  and  presented  in 
the  SEAWOLF  sectional  construction 
drawings  represents  a  major 
achievement  in  the  practical 
application  of  concurrent  engineering. 
The  availability  of  the  SEAWOLF 
electronic  data  base  was  key  in  making 
the  transition  from  the  system  to  zone 
design  possible.  The  utility  of  the 
data  base  is  also  being  exploited  to 
make  early  inroads  into  the  many 
products  required  for  the  logistics 
support  of  the  ship.  Design  is  the 
first  phase  of  logistics  support.  As 
the  designer  creates  the  ship,  the 
individual  components  are  chosen  to 
meet  the  requirements  of  the  system. 
These  components  become  the  foundation 
of  the  effort  required  to  maintain  the 
ship  in  a  proper  condition  of 
readiness.  The  design  data  base  is 
the  key  resource  from  which  the 
initialization  of  logistics  support 
systems  can  be  accomplished.  The 
SEAWOLF  logistics  group,  in 
cooperation  with  the  design  yards,  is 
putting  into  place  the  systems  to 
electronically  extract  information 
from  the  design  data  base  and  create 
the  computer  driven  systems  that  will 
in  turn  create  the  products  necessary 
to  support  the  SEAWOLF  class  submarine 
throughout  its  life  cycle.  The 
systems  that  will  fulfill  this 
function  have  been  integrated  under 
the  umbrella  system  known  as  SAILSS. 
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The  creation  and  utilization  of  a 
computer  based  logistics  effort 
represents  a  milestone  as  important  in 
the  logistics  phase  as  the  digital 
data  transfer  effort  has  been  in  the 
construction  phase  of  the  life  cycle. 


SF.AWOT.F  ATITOMATFD  INTEGRATED  LOGISTIC 
SYSTEM 

Integrated  Logistic  Support  (IIS)  is 
a  process  concerned  with  capturing  the 
configuration  of  the  ship  and 
producing  and  maintaining  the  logistic 
products  (maintenance  plans  and 
standards,  piece  part  support  and 
allowances,  technical  manuals,  etc.) 
that  support  the  ship's  operation. 
Because  these  products  have 
historically  been  developed  and 
maintained  utilizing  independent  data 
bases,  the  information  contained  in 
them  is  often  not  in  agreement.  For 
example,  piece  part  requirements  can 
differ  between  the  ship's  allowance 
list,  the  technical  manual  and  the 
repair  standard.  The  lack  of 
integration  with  the  ship's  logistic 
products  results  in  wasted  man  hours 
and  a  high  degree  of  frustration  for 
the  people  performing  maintenance. 


To  improve  the  efficiency  and 
effectiveness  of  Integrated  Logistic 
Support  (IIS)  for  the  SEAWOLF  Class 
Submarine,  PMS350  early  in  the 
development  process  sought  to 
integrate  the  various  ADP  systems  that 
provide  this  support.  The  historic 
disconnects  that  have  existed  between 
the  various  logistic  products  could 
only  be  corrected  by  integrating  the 
systems  that  produce  and  maintain 
these  products.  This  need  led  to  the 
development  of  the  SEAWOLF  Automated 
Integrated  Logistic  Support  System 
(SAILSS) .  SAILSS  will  provide  an 
automated  ILS  system  that  will  support 
the  class  during  both  the  acquisition 
and  operation  phases. 

SAILSS  is  being  designed  as  a 
distributed  data  base  (information 
resides  in  more  than  one  ADP  system) 
developed  and  dedicated  to  the 
logistic  support  of  the  class.  The 
system  is  being  designed  as  a 
composite  of  individual  subsystems 
(See  Figure  6) ,  linked  by  common  data 
elements,  software  and  a 
telecommunication  network  with 
controls  to  prevent  access  of 
unauthorized  individuals.  NNS  is  the 
system  developer  and  has 
responsibility  for  the  design, 
development,  testing  and  associated 
documentation  of  the  system. 


LOGISTIC  PRODUCTS 


FIGURE  6.  SEAWOLF  AUTOMATED  INTEGRATED  LOGISTICS  SUPPORT  SYSTEM 
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Early  in  the  development  it  became 
apparent  that  a  methodology  was  needed 
that  would  provide  commonality  between 
the  various  SAILSS  data  bases. 
Additionally,  since  logistics  is 
concerned  with  the  ship’s 
configuration,  a  link  common  to  both 
SAILS  and  the  design  data  base  was 
required.  SEAWOLF  utilizes  the 
Functional  Group  Code  (FGC)  for  this 
linkage.  The  code  provides  an 
indexing  system  that  establishes  the 
basis  for  the  structuring  the 
configuration  records.  An  example  of 
a  FGC  is  contained  in  Figure  (7). 


Configuration  Management  Sub-system 

The  primary  sub-system  within  SAILSS 
supports  the  configuration  management 
process.  The  purpose  of  this 
subsystem  is  to  capture  the  functional 
configuration  (generated  during  the 
design  process)  and  to  build  upon  this 
baseline  by  adding  the  physical 
configuration  (an  item  identified  to  a 
specific  vendor  that  satisfies  the 
function)  information  identified 
during  the  construction  process. 

The  following  isr  a  very  simple 
outline  of  the  configuration  process 

and  how  FGC  is  involved  in  the 
process.  As  systems  are  developed  the 
design  engineer  determines  that  an 
item  is  required  in  the  system  to 
perform  a  specific  function,  e.g., 
pump  water.  These  items  are  added  to 
the  system  drawing,  a  file  in  the 
design  data  base.  The  system  drawing 
is  reviewed  by  the  system  engineer  who 
assigns  a  FGC  to  the  individual 
functional  items.  This  information  is 
loaded  into  both  the  design  and 
Configuration  Management  data  bases. 
The  physical  configuration  items  are 
later  identified  by  the  shipbuilder 
and  electronically  transferred  to  the 
corresponding  FGC  in  the  configuration 
management  sub-system. 


Currently,  a  prototype  that 
electronically  links  SAILSS  and  the 
design  data  base  is  being  developed  to 
take  advantage  of  the  fact  that  the 
FGC,  as  well  as  other  logistic  related 
information,  is  in  the  form  of 
processible  text.  During  the  analysis 
phase  of  this  project  it  became 
apparent  that  information  that  is 
important  to  the  designer  may  not  be 
important  to  the  logistician  and  vice 
versa.  For  example,  oulkheads  and 
other  structural  items  are  not 
normally  considered  as  a  configuration 
items  by  the  logistician  but  are  by 
the  designer.  Because  of  these 
differing  views  of  the  submarine,  a 
review  by  the  logistics  engineer  in 
the  initial  integration  of  the  two 
systems  will  be  required.  However, 
once  the  systems  are  linked,  the 
capability  to  compare  configuration 
information  between  the  two  data  bases 
will  exist.  This  ability  ensures  that 
changes  in  the  design  are  captured  by 
the  logistician. 

The  Configuration  data  base 
electronically  provides  configuration 
information  to  the  various  sub-systems 
within  SAILSS,  as  well  as  external 
data  bases.  Use  of  these  interfaces 
will  allow  sharing  of  data  and  will 
increase  the  accuracy  of  the  data. 


Logstic  Support  Analysis  Sub-svstem 

Logistic  Support  Analysis  (LSA)  is  a 
process  that  documents  the  engineering 
rationale  on  which  the  maintenance 
concept  (repair  activity  capability, 
periodicity,  and  technical 
requirements)  is  based  and  stores 
source  data  from  which  individual 
logistic  products  are  developed. 

Since  the  LSA  process  utilizes  a  data 
base  that  is  linked  to  other  SAILS 
sub-systems,  consistency  with  the 
analysis  and  other  ILS  products  is 
assured. 


FGC 


FUNCTIONAL  NOMENCLATURE 


420 

423 

4231 

42311 

42312 

42313 

42314 

4232 
42321 


NAVIGATION  SYSTEM 

ELECTRONIC  NAVIGATION  SYSTEMS,  RADIO 
DIRECTION  FINDER  SET  AN/XXXX 
ANTENNA  ASSEMBLY  AS-XXXX 
RECEIVER-PROCESSOR  R-XXXX 
CONTROLLER-INDICATOR  C-XXXX 
SWITCH-MULTIPLE  ROTARY 
NAVIGATION  SYSTEM,  OMEGA 
RECEIVER-COMPUTER 


FIGURE  7.  FUNCTIONAL  GROUP  CODE  (FQC)  INDEXING  CONCEPT 
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The  SEAWOLF  project  was  the  first  to 
utilize  the  unified  data  base  (UDB) 
software,  which  was  developed  by  the 
Air  Force,  as  the  means  to  automate 
the  LSA  record  (LSAR)  .  The  Naval  Sea 
Systems  Command  Logistics  Center 
(NAVSEALOG)  has  been  designated  as  the 
custodian  of  this  software.  It  is 
also  planned  that  the  UDB  will  be 
enhanced  to  include  NAVSEA  specific 
data  elements  not  currently  defined  in 
MIL-STD-1388. 

The  LSAR  is  designed  to  utilize 
control  numbers  to  identify  the 
component  undergoing  analysis. 

SEAWOLF  uses  the  FGC  as  the  Control 
number,  which  will  be  electronically 
transferred  to  the  LSAR  from  the 
Configuration  Management  Sub-system. 
This  ensures  all  configuration  items 
identified  during  the 
design/construction  process  are 
analyzed  for  logistic  support 
requirements.  Additionally,  logistics 
support  data  produced  by  the  LSA 
process  will  be  distributed 
electronically  between  this  system  and 
other  sub-systems  of  SAILS,  as  well 
as  external  data  bases,  for  the  actual 
production  of  logistic  products. 


Integrated  Publishing  System 

The  Integrated  Publishing  System 
(IPS)  is  a  computer  based  system 
designed  specifically  to  produce  and 
maintain  a  wide  variety  of  technical 
documentation.  The  system,  which  is  a 
sub-system  within  SAILSS,  consists  of 
a  combination  of  state  of  the  art 
hardware  and  software  which  provides 
for  technical  matter  publication  and 
life-cycle  maintenance. 

IPS  provides  the  speed  and  power  to 
achieve  high  level  of  performance  by 
replacing  manual  production  tools  and 
methods  with  computer  function.  The 
sub-system  provides  for  the  electronic 
tools  to  assist  in  the  collection  of 
source  data,  including  IGES  transfer 
of  drawings  from  the  design  data  base 
and  interfaces  to  scanners  for  reading 
in  hard  copy  drawings.  The  capability 
to  transfer  data  directly  from  LsAR  to 
the  system  will  be  developed. 
Additionally,  other  time  consuming 
tasks  such  as  page  composition  have 
also  been  automated.  The  merging  of 
text  and  graphics,  once  a  time 
consuming  task,  is  now  automated  and 
the  composition  of  a  camera  ready  page 
is  now  a  relatively  simple  task. 


SUMMARY 

There  is  a  large  body  of 
organizations,  government  and 
industry,  that  are  studying  the 
concept  of  information 
transportability  throughout  a  weapons 
system  life  cycle.  The  conclusions 
being  reached,  almost  universally,  are 
the  free  flow  of  data  from  one  phase 
of  the  acquisition  to  another 
represents  the  greatest  potential  to 
reduce  life  cycle  cost  and  improve  the 
overall  performance  of  the  system. 

However,  in  today's  world  there 
appears  to  be  too  much  information  and 
too  little  experience  in  structuring  a 
long  term  program  that  utilizes  the 
envisioned  potential.  Beyond  the 
challenges  of  capital  investment, 
cultural  shock  in  the  work  force  and 
the  need  to  restructure  traditional 
phases  of  acquisition,  the  very  basic 
questions  of  "how  do  I  structure  my 
program  and  where  do  I  go  for  help?" 
do  not  have  clear  answers .  The 
SEAWOLF  program  was  driven  by 
necessity  to  search  for  the  answers 
concerning  data  base  structuring  and 
utilization.  The  simply  stated 
problem  of  "how  do  I  transfer  CAD  data 
between  NNS  and  EB  Div"  has  taken  a 
significant  effort  to  resolve.  The 
SEAWOLF  Program  has  made  steady 
progress  in  utilizing  the  design  data 
base  to  improve  the  efficiency  of  the 
other  phases  of  the  ship's  life  cycle. 

The  Program  Manager  of  any  future 
weapons  system  acquisition  will  be 
charged  with  the  responsibility  to 
implement  a  strategy  that  more 
completely  integrates  ship  design, 
construction  and  logistics.  The  only 
method  to  affordably  accomplish  that 
task  is  to  create  and  utilize  snared 
electronic  data  bases.  The 
achievement  of  an  essentially  "paper 
less”  environment  that  supuorts  a  free 
flow  of  data  between  life  cycle  phases 
is  a  significant  goal  that  successive 
programs  should  undertake  as  a 
principal  requirement.  The  Department 
of  Defense  has  recognized  the  need  for 
computer  aided  acquisition  and 
logistic  support  systems  and  has 
formulated  policy  that  mandates  the 
creation  of  government  accessible 
electronic  data  bases.  The  Program 
Manager  must  require,  as  part  of  the 
contract,  the  tasking  to  create  and 
utilize  data  bases  in  a  program 
tailored  to  support  the  life  cycle. 

The  lessons  learned  by  the  SEAWOLF 
program  in  this  field  are  a  major 
milestone  in  the  effort  to  more  fully 
realize  the  potential  of  advanced  ship 
production  techniques. 
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